


DTL-BASIC 


Copyright 


The contents of this manual and the disks supplied with the manual 
are copyrighted (c) 1981 by Drive Technology Ltd. 


Copying of either disks or manual or the transmitting of information 
contained herein by any means whatsoever whether mechanical, 
electrical or electronically is strictly forbidden. Users “are 
reminded that a condition or purchase is the acceptance that 
copyright rests with Drive Technology Ltd. and that full - 
responsibilty rests with the registered user to protect such 
copyright. Copies of individual files may be made for security uses 
only by the registered user. 


License 


DTL-BASIC is licensed to the registered user on the clear and 
explicit understanding that compiled programs, whether or not owned 
by the registered user, shall not, by way of trade or otherwise, be 
lent, re-sold, hired out or otherwise circulated. The registered user 
of DTL-BASIC is licensed to compile programs for the sole use of 
the user. | a 


Where a user wishes to circulate copies of compiled programs, then 
details of the necessary license may be obtained from the 
Distributors. 


Scope 


DTL-BASIC should only be used to compile programs that are the 
purchaser's property. Programs that are licensed for use by a third 
party may have their copyright violated if compiled. The purchaser is 
advised to check with the program supplier before compiling any 
programs that are not owned by the purchaser. 


Unless the Distributor is contacted in writing within 10 days from 
the shipment of this program, it shall be assumed by the Distributor 
that the registered user has read and fully accepted the above 
conditions. 


Reg. User eoeeseess @e@#eee*eeesse#eeee#egee#e##ee# 


POlta BO oe ee ea eee eee wees Sole Distributor 
Dataview Limited 
Portreeves House 
East Bay, Colchester 
Essex, COl 2XB, England 
Tel: Colchester (0206) 865835 
Telex: 987562 
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DTL-BASIC Release 4 ~ Changes from Release 3 


1, The main change in this release is the use of a protection system 
based upon security keys rather than protected disk (see sections 3 
and 9). This has several advantages ; 


- backup copies can be made of program disks; 
- program disks can be write protected; 


~ cassette based and Computhink disk based programs can be 
protected; 


-~ the standard version of the compiler produces protected 
programs so that there is no additional cost to gain the 
benefits of protection. 


2. The mechanism for compiling extensions to BasSic has been improved 
to handle extensions starting with keywords and SYS calls with 
parameters. In addition the compiler has now been used successfully 
with several ROM based products (see Appendix D). 


3. The replacement for CONT (ie. SYS1069) is more compatible in that 
it can re-start the program after a STOP or END statement and after 
Return has been hit on an INPUT statement. 


4. The compiler now gives warning messages when it detects an 
extension to Basic. This is because syntax errors can appear to the 
compiler as extensions to Basic and the compiler will therefore not 
give an error message. If a warning message occurs on a line not 
containing an extension then it indicates a syntax error. 


5. When the compiler produces a listing it first checks that 5ST 
equals zero and if not waits until it becomes zero. This has caused 
problems on some printers that generate a non-zero ST value when 
ready. In release 4 the compiler waits until ST equals zero or until 
Space is pressed thus enabling listings to be obtained on 
non-standard printers. 


1. Introduction. 


DTL~BASIC 1s a Basic compiler for Commodore machines and is fully 
compatible with the Commodore Basic Interpreter (with a few very 
minor exceptions). 


This manual describes how to use and operate DTL-BASIC. The manual 
does not try to define the Basic language or to teach Basic 
programming as these subjects should be adequately covered by the 
Commodore documentation. | ? 


Readers of this manual who are not familiar with the differences 
between interpreters and compilers should refer to Appendix A. 


The main advantages of DTL-BASIC are :- 


- compiled programs run much faster than on the Interpreter. The 
speed improvement depends upon the size and nature of the 
program and upon the time involved in fixed overheads (e.g. disk 
accesses and printing etc.) but statements within large programs 
may run up to 10-20 times faster. 


-~ the compiler is almost totally compatible with the Interpreter 
so that existing programs can simply be re-compiled without 
alteration to obtain all.the benefits of compilation. The main 
exception to this is programs that obviously cannot be 
compiled,e.g. ones that alter themselves; see section 7 for the 
133% 1Oe other incompatabilities. The high degree of 
compatability means that new programs can be developed on the 
Interpreter as this is easiest for debugging and when working 
can be compiled. 


~ the compiler implements true integer arithmetic as well as 
real arithmetic (the Interpreter allows integers but converts 
them to reals for all operations) and the use of integers can 
lead to significant speed improvements. Special facilities are 
provided to automatically convert reals to integers when 
compiling existing programs. 


~ the compiler will accept extensions to Basic implemented by 
Assembler routines in RAM or ROM (Such as used with Computhink 
disks and such chips as Command-O etc.) and in fact the compiler 
should be compatible with the vast majority of Assembler 
routines that can be used with the Interpreter. 


~ compiled programs require approximately 50-80% as much = store 
as un-compiled programs. However, there is a fixed overhead of 
16 blocks so that small/medium sized programs of about 50 blocks 
or less will not achieve a store saving. 


- compiled programs cannot be listed or altered by a user. 


-~ use of the compiler can result in significantly reduced 
development and maintenance costs. ei 


* 


-compiled programs utilise stack space more efficiently than the 
Interpreter thus enabling more complex programs to be run. 


-the compiler is fast. Compilation speed is typically 1-2 
lines/second. The compiler itself is mainly written in Basic and 
is used to compile itself. This demonstrates that the compiler 
can be used to compile very large, complex programs (the source 
of the compiler is a file of 95 blocks). 


~compiled programs can disable the stop key without affecting 
the clock. 


Section 6 describes the advantages of using DTL-BASIC in more detail 
to enable users to fully obtain the benefits possible with the 
compiler. : 


Configurations 


Three versions of the compiler are avaiable for the following 
Machines :; 


DTL-BASIC ; 
Version number Machine 

: | CBM 3032 

2 CBM 4032 

3 CBM 8032 


A program compiled by Version 3 will run on a 4032 and a program 
compiled by version 2 will run on an 8032. 


A printer can be used with the compiler but is not essential. The 
compiler only uses upper-case ASCII characters. 


2. General Description of DTL-BASIC. 


This section describes the main features and capabilites of 
DTL~BASIC. 


The original aims in designing the compiler were ;: 


-that any program that will run under the Interpreter 
should be able to be compiled without modification; 


-~that the compiled programs should run much faster than 
under the Interpreter; 


~that apart from running faster the compiled programs 
should operate exactly the same way as un-compiled 
programs; 


-that compiled programs should if possible be smaller than 
un-compiled programs. 


The first requirement listed above was seen as the most important 
as there are now many very large Basic programs available and if the 
compiler applied arbitrary limits to (say) the number of variables 
that were allowed then many users would find that the programs that 
they most wanted to compile could not be compiled. Secondly it was 
felt that although a compiler has many advantages over an Interpreter 
the great feature of an Interpreter is the ease in which a program. 
may be debugged. However fast a compiler is to compile a program it 
will almost always be faster to develop a program using the 
interpreter. Consequently the major aim has been to achieve almost 
total compatability with the Interpreter thus enabling the Compiler 
and Interpreter to be used together so that program developers can 
take advantage of the best features of each system. 


The second requirement was to make compiled programs as fast as 
possible. This requirement to some extent conficts with the first in 
that if the compiler was made to produce the fastest compiled 
programs possible, then the compiled programs would probably | be 
several times larger than the un-compiled programs. This would mean 
that only fairly small programs could be compiled and would make the 
compiler of only limited use. 


DTL~BASIC has been designed to achieve the ideal balance between 
speed and size so that for large programs the Basic statements will 
run at about 20 times faster than on the Interpreter but each 
statement will typically require between 50 and 80% as much. store. 
The reduction of 20-50% in size is necessary because each compiled 
program has to contain a Run-time library of 16 blocks (ie. 4K 
bytes). This means that small programs when compiled will require 
more store; but for programs of over about 50 blocks then the 
compiled program should be smaller than the un=-compiled program. 


It should be noted that all the figures given on the previous page 
are typical figures and the actual figures for specific programs may 
vary considerably. For example the speed saving very much depends 
upon the nature of the program. If the program is making a large 
number of disk accesses and is not doing much processing then 
although individual statements may execute about 20 times faster the 
overall speed improvement could be much less than 20 times. The best 
results will only be achieved if maximum use is made of integer 
variables (see section 5 for an explanation of how to do this’ for 
existing programs). 


Similarly, if a program is written with many REM statements and with 
only one statement on each line then the store saving from 
compilation could be much better than the figures quoted earlier. [In 
contrast to this a program with no REMS and many statements on each 
line would probably not achieve the percentage reduction quoted. 


It should also be’ noted that although DTL-BASIC is designed to 
compile any programs there are some programs that it is not sensible 
to compile,eg. programs which list themselves or which re-number 
themselves. This is obviously because the source of the program is 
not in store when the program is run. 


The rest of this section describes the structure of the compiler and 
the facilities that it provides. 


2.1 The User Interface. 
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The above diagram shows the main points of interaction between the 
compiler and the user. 


The Source file is the main input to the compiler and is a perfectly 
standard Basic program file,ie. the Source file contains a Basic 
program that can be LOADed and RUN. The file can also be edited and 
LISTed in the normal manner for Basic programs. 


The Object file is the main output from the compiler and contains the 
compiled program. As far as the Interpreter and DOS are concerned 
this file is also a program file and can also be LOADed and _ RUN. 
However, because the file contains the compiled version of the source 
File it cannot be edited or LISTed. Changes can only be made to an 
object file by editing the source file and re-compiling. 


The LN (Line Number) file is essentially a workfile of the compiler 
and is used to relate line numbers to their addresses within the 
Object file (the Object file does not contain any line numbers). The 
LN file is not required to run the program and may be SCRATCHed. 
However, if the program is not fully debugged the LN file should be 
retained as it can be used to locate run time errors by the ERROR 
LOCATE program (see section 8.3). 


The compiler can be instructed to list the source file on the printer 
whilst it is being compiled. 


The compiler performs exhaustive syntax checks and an error message 
1s output for each error found. The compiler can output the error 
messages to either the printer or the screen. If errors are output to 
the screen the compilation is suspended when the screen is full of 
error messages so that the errors may be noted before the compilation 
ig resumed. 


The statistics that can be produced by the compiler relate to the 
Object file and give the size of each of the main sections within the 
file (see section 2.3). This information is provided to enable the 
programmer to see how the store is being used. It is important to use 
the statistics when comparing the size of compiled programs with. 
uncompiled programs (rather than simply comparing the file sizes). 
This is because the Object file includes the variable list (ie. the 
list of all non-array variables). This saves having to create the 
variable list every time the program is run, but means that the 
Object file may be several blocks larger than the actual program 
size. The statistics given by the compiler include both the actual 
program size and the Object file size. 


The Options file is used to record the options selected by the user 
when the program is run,ie. 


- the Source file name; 


the Object file name; 


whether the source is to be listed; 


- whether errors are to be listed; 


whether the statistics are required; 
-~ the text message to be used to identify any listings. 


When the compiler is run it looks for the Options file and if it 
exists then the data is displayed to the user who can change the data 
if necessary before starting the compilation. Often when a program is 
compiled a number of times the options will not need to be changed 
and the user will avoid a lot of repetitive typing. 


2.2 The Internal Structure. 
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FIGURE 2 


This section describes the internal working of the compiler in more 
detail. The figure above is the same as figure 1 with additional 
detail added to show all the files involved during compilation. 


DTL-BASIC is a two pass compiler,i.e. it processes the program twice 
to produce the Object file. | 


The main stages involved in the first pass are : 


~ the Options file is read (if it exists) and the contents 
displayed to the user. 


~ the User changes (or inputs) the option data as necessary and 
starts the compilation. 


- the compiler deletes any existing Options file and creates a 
new one. 


~ the specified source file is opened and is processed statement 
by statement. Whenever a line number is found an entry is made 
in the LN file. If a statement is a DATA statement it's contents 
are output to the Data Statement file. For other statements the 
Syntax is checked and code is output to the Semi-compiled file. 
This code is not complete because any line numbers will have not 
been converted to an adddress and references to variables will 
be relative to the start of variables rather than absolute 
addresses, 


- as each line is precessed then if source listing was selected 
then the line ‘is output to the printer. 


- if a syntax error is detected an error message 16 OUTDAE “ko 
either. the screen ar the printer, 


At the end of pass 1] the compiler has built up internally a list of 
all variables and knows the amount of memory required for compiled 
code and data statements. It can therefore calculate the absolute 
addresses of all variables and it also has (in the LN file) the 
address of each line. 


The operations involved in pass 2 are : 


- the Object code file is created and the contents of the 
Run-time library file copied to the Object file. 


- the contents of the Data Statement file are copied to the 
Object file. 


~ the Semi-~-compiled file and the LN file are processed together 

and the code for each statement is first completed by changing 

line numbers to addresses and making the addresses of variables 

absolute instead of relative. The completed code is then output 
to the Object file. 


- as the code is completed any references to non-existent lines 
are detected and an error message is output. 


- once all the completed code has been output to the Object file 
then the Data Statement and Semi-compiled files are deleted. 


- the compilation statistics are output (if required). 


2.3 The Object file structure. 
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Figure 3 shows the internal structure of the Object file. 


The Run-time library is a set of routines that are incorporated in 
each compiled program and which implement such functions as integer 
arithmetic, FOR loop control etc. 


The Data statements section consists of the text from all Data 
statements in the program . 


The Compiled code is the actual program and consists primarily of 
calls to routines that are within the Run-time library. 


The Variable list contains an entry for each scalar variable (ie. 
each non-—array variable) used in the program. The format of the 
variable list is the same as the list used by the Interpreter. The 
Variable list is included in the program so that it does not have to 
be re-created every time that the program is run as is the case for 
the Interpreter. 


Note that a facility is provided to create an Object file without a 
Run-time Library (see ** NL command in Appendix B). This facility can 
be used for programs that are never run on their own but are always 
LOADed from other programs (ie. for overlays), the advantage is that 
the Object file will be significantly smaller. and will therefore save 
disk space and LOAD faster. 


3. Installation of DTL-BASIC. 


Contents. 


DTL-BASIC compiler disk 
DTL~BASIC manual 
‘'Compiler' security key 


DTL~BASIC is supplied on a single floppy disk which is write 
protected and the first action should be to take several copies of 
the disk for backup purposes. 


In order to protect Drive Technology's copyright and the copyright of 
DTL~BASIC users over their own programs DTL-BASIC incorporates a 
protection feature that ensures that the compiler and compiled 
programs will only run in the presence of a special security key 
attached to one of the machines cassettte ports. 


The security key marked 'Compiler' supplied with DTL-BASIC must _ be 
fitted to one of the cassette ports before the compiler will run. 
Each CBM model has two cassette ports (refer to your Commodore manual 
if you do not know the location of the cassette ports) and the 
Compiler key may be fitted to either. It is important to fit the key | 
the correct way;lie. ensure that the side marked 'top' faces upwards. 
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IMPORTANT 


Always ensure that the machine is switched 
off before fitting or removing a security 
key. This is especially true when fitting 
the key to a port within the system eg. 
the first casettte port on a 3032. 
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4. Operation of DTL-BASIC. 
DTL~BASIC has been designed to be very simple and easy to use, 
To run the compiler : 


-insert the compiler disk in drive 0 and the disk containing the 
program to be compiled (ie.the Source file) in drive 1; 


~ensure that the ‘Compiler' security key is fitted; 


~load and run the first program on drive zero; 


The compiler will first initialise drive 1 and display a list of 
options on the screen. If it is the first time that the compiler has 
been run on the disk in drive 1 then the option input fields will be 
blank. Otherwise the fields will display the options selected the 
last time the compiler was run on that disk and it will only be 
necessary to type in any alterations. 


On the first run the option input fields will be blank and it will be 
necessary to type : 


~the name of the Source file 


~the name of the Object file (ie. the name to be used for the 
compiled program). Any existing file of this name on drive l1 
will be overwritten. 


If no listing is required simply key f to start the compilation. The 

key 1S normally used to start the compilation and indicates to the 
compiler that the information displayed is correct and the 
compilation is to start. 


If any form of printing is required then answer Y or N to _ the 
remaining questions (followed by Return). Before typing any field f 
can be keyed to start the compilation,ie, a blank field indicates a 
No answer. 


If the printer is to be used the compiler will first print a heading 
containing the data from the screen. The contents of the ‘Run 
Identity’ field are included in the heading so that individual 
listings can be identified. For example the 'Run-Identity' could be 
the time and/or date so that when various listings are produced their 
chronological sequence can be determined. Another way of doing this 
is to type a 'Run Identity' of *<number>. When the compiler detects 
the # it will store #<number+l> in the Options file so that each 
listing will have a separate number. 


Before typing a field then<— can be keyed to exit from the compiler 
or / can be keyed to enable a new file disk to be loaded. If the 
field contents are OK then Return can be keyed to move to the next 
field. 


The compiler allows the user to specify any name for the Object file 
but the compiler will generate the Object file name automatically if 
the following convention is used : 


- 1£ the Source file name ends with the string "-SRC" 
e.g. if the Source file name is 
TEST~SRC 
then the compiler will automatically call the Object file 
TEST 
Note 


1. If one program LOADS another program then if the LOAD statement is 
not to be changed the the source file will have to be re-named before 
compilation. For example, if there are two programs in files PROGA 
and PROGB and they are both compiled to produce the Object files 
C-PROGA and C-PROGB; and if PROGA contains the statement ;: 


LOAD "PROGB",8 


then when C-PROGA runs it will load the source of the second program 

rather than the Object file. The best solution would be to RENAME the 
files to be PROGA-SRC and PROGB-SRC before starting the compilation. 
This would produce Object files called PROGA and PROGB' respectively 
so that the LOAD statement would work correctly. 


2. If Source files are RENAMEd then the disk (or at least the file) 
should be copied to create a new file and the new file should be 
compiled rather tha the renamed file. This is because there appears 
to be a bug in DOS that can cauSe errors if a file is compiled 
immediately after being renamed (alternatively INITIALISE drive 1 
after a RENAME). 
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3. The compiler will not work correctly if the DOS Support utility is 
loaded. 


4. As the compiler runs it will check for any disk errors and will 
report them on the screen. After an error the user can key Space to 
re-start the compilation. If the error is a fatal one (e.g. DISK 
FULL) the user can exit from the compiler by keying <—- when the 
options are displayed. : 


5. As-explained earlier the compiler performs two passes on the 
program. During each pass the line number being compiled is displayed 
and any errors detected are displayed on the screen or printer 
depending upon the option selected. 


6. If any output is to be made to the printer the compiler will check 
that the printer is ready before starting the compilation;ie. that 
the i/o status variable ST equals 0. If ST is not equal to zero the 
compiler will wait until it either becomes zero or until a space is 
pressed (the option to press space is provided because some printers 
are non-standard and have a non-zero ST value when they are ready). 


7. AS was explained in section 2 the compiler creates several files 
on drive 1 so that a certain amount of free space must be available 
when the compilation starts (the amount of space needed depends upon 
the size of the program being compiled). 


The files created are : 
-~the OPTIONS file which is always 1 block. 


-~the Object file which will typically be eaten file size * .5 
) +. 26 DLOCKs 20ng. 


—~the LN file which will have the same name as the Object file 
with the prefix "LN-". There is one record in the file for every 
line in the program and each record consists of 4 bytes. 


-the Semi-compiled file is called W3 and will typically be 
(Source file size * 0.5) blocks long. 


~the Data Statement file is called Wl and will only be created 
if the program contains any DATA statements. The file contains 
the contents of all the DATA statements in the program. 


8. At the end of the compilation Wl and W3 are automatically deleted 
but if for some reason the compilation is not allowed to complete 
normally then the files may be left on Drive l. If this occurs’ they 
will be deleted on the next compilation. 


9. After the compilation is complete the Object file can be LOADed 
and RUN. However if the program in the Object file LOADS any other 
programs then these too must have been compiled otherwise they will 
not run, | 


10. Although the compiler requires a 32K machine with disks, compiled 
programs will run on 8 or 16K machines (depending upon the programs 
size) and can be held. on cassette, 


ll. Where the direct command CONT would be used for an Interpreted 
program SYS1069 should be used for a compiled program. SYS1069 will 
therefore restart a program after the STOP key has halted the program 
or after it has obeyed a STOP or END statment. sSYS1069 will also 
restart a program that has halted because RETURN was hit on an INPUT. 


12. When a compiled program is run and some results of arithmetic 
calculations are found to be wrong then it is likely that the program 
should be compiled with special integer mode selected (see section 
a) 


13. A compiled program should not be SAVEd to create a new copy of 
the program once the program has been RUN. 


14. To disable the Stop key without affecting the clock use _ the 
statement POKE 1072,1 and use POKE 1072,0 to re-enable it. Note that 
if it is required to run the uncompiled program on the Interpreter 
the Interpreter should not obey the above statements. One way of 
preventing the statements being obeyed by the Interpreter would be : 


IF PEEK(1025) = 11 THEN POKE 1072,1 


This works because location 1025 always holds 11 in compiled programs 
(the user should check that 1025 does not hold 11 in the uncompiled 
program - if it does then change the length of the first line in the 
program). Note that compiled programs with the Stop key disabled run 
marginally faster (ie. up to 2% faster). 


15. Compiled programs that are used together, ie. that LOAD each 
other must all be compiled by the same version of the compiler at the 
same Release (the Release number is the second digit of the compiler 
identifier, eg. DTL-BASIC 2.4 is version 2 release 4). 


16. When a program is compiled with only the 'Compiler' key fitted 
then the compiled program itself will only run on a machine with the 
‘Compiler' key fitted. Normally this will be no problem as_ the 
compiled program will be run on the machine on which it was compiled. 
See section 9 if it is required to run the compiled program on a 
number of machines. 
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5. Integer Arithmetic Facilities. 


Commodore Basic supports integer as well as real variables. 
Unfortunately, the Interpreter does not. perform true integer 
operations as it converts all integer values to real format before 
performing any operation. The result of the operation is then 
converted back to integer. A consequence of this is that if integers 
are used then the program will actually run slower because of the 
mode conversions on each operation. For this reason most existing 
programs do not use integers even though the vast majority of 
variables normally hold integer values. Integers are sometimes used 
for arrays as this gives a space saving. 


DTL-BASIC differs from the Interpreter in that it implements true 

integer operations for all ~ operators when both operands are 
integer,i.e. all arithmetic,boolean and relational operators. New 

programs which are to be compiled should therefore use integers 

wherever possible. 


The arithmetic package within the Run-time Library has been designed 
to achieve true compatability with the Interpreter and to ensure that 
the best results are achieved it will help to understand the 
following points : 


i. Wherever possible parts of expressions are calculated in integer 
mode and the result converted to real where necessary, e.g. in the 
expression - 


A = J%*(I%*10+6) + B 


the underlined section would be calculated in integer mode and 
the result converted to real for the rest of the statement. 


2s Whilst in integer mode then if integer overflow occurs’ the 
operands are converted to real and the operation is repeated in real 
mode, e.g. in the above example if I% holds 30,000 then the integer 
multiplication by 10 would cause overflow as the value would exceed 
32K and the operation would be repeated in real mode. 


3. If integer overflow is very likely the programmer can avoid it by 
uSing real constants. 
eg. if the above statement is written as : 
A = J&*(I$*10.0+6) + B 
then all operations will be in real mode. 
4. Special consideration is needed for the operators divide and 
exponentiation because when applied to integer operands they can 
yield a fractional result. The compiler cannot know whether the 
programmer requires the fractional part or not,e.g. the expression. 
3/2*4 ‘ 


will yield 4 if integer operations are used and 6 for real 
operations. 


If not instructed otherwise the compiler will perform integer divide 
and exponentiation when both operands are integer (the above example 
would therefore normally give the answer 4). This option was chosen 
because it is normally what the programmer requires and because it 
runs the fastest. 


If the programmer wants a real divide or exponentiation then there 
are two ways of achieving it : 


a - make sure at least one of the operands is real 
e.g. 3.0/2%*4 


b - use the Special Integer mode of compilation. 


In the Special Integer mode ALL divide and exponentiation operations 
involving integers are real. This mode can be selected by including 
the statement : 


REM ** ST 


before any statements (other than REMs) at the start of the 
program. Note that the statement is in the form of a REM so that the 
program will still run under the Interpreter. 


5. If an existing program is being compiled and any problems are 
found with the results of calculations then Special Integer mode 
should be used as this makes the arithmetic fully compatible with the 
Interpreter. 


6. As has been explained programs that use Integers as mich as 
possible will run faster than if reals are used. This is fine for new 
programs but what about existing programs ? It is a lot of work to 
edit existing programs to use integers and the edits may introduce 
errors. . 


DTL-BASIC includes a special feature that can convert variables (both 
scalars and arrays) automatically to integers without any changes to 
the program. There are two ways of doing this depending upon the 
number of variables to be converted. , 


The first method is to use a ‘Convert Specific’. statement at the 
start of the program. This instructs the compiler to convert the 
named variables to integers,e.g. 


REM ** CS (Al,ZZ,X2,X3) 


This instructs the compiler that the named variables are to be 
converted to reals. In the example the variables will become 
A1%,Z22%,X2% and X3%. The compiler will flag an error if variables 
with these names already exist. In order to avoid name clashes the CS 
Statement can be modified to specify new names for some or all of -the 
variables,e.g. if 22% already exists but Z0% does not exist then the 
statement would become : 


REM ** CS (Al1,2Z.=>.20Q%,X2,X3) 


‘ 


Note : 


~when a name change is specified then the first character of the 
two names must be the same; 


-there can be several CS statements but the maximum number of 
variables that can be converted is 128; 


~if the variable to be converted has more than 2 characters in 
it's name then only the first 2 should be used used in a CS ‘or 
CE statement. 


When a large number of variables are to be converted it will be 
better to use the second method of conversion. This is specified by 
the ‘Convert Excluding' statement and converts ALL real variables 
excluding those explicitly named,e.g. 


REM ** CE {) 
will convert all reals; 
REM #* Ce AL dye eyo 
will convert all reals except those named I1,I2 or 13. 


The conversion rules are the same as for the CS statement and name 
clashes can be avoided in a similar way,e.g. 


REM ** CE (A,B => B1$%,C) 


will convert all reals excluding those named A and C. Variables 
named B WILL be converted and will be converted to Bl$%. : 
Note that CS and CE statements cannot both be used in the same 
program but an SI statement can be used with either. Also, if any of 
these special statements are used then they must be the first 
statements in the program, otherwise they will be ignored. 


7. j|Even for new programs there may be a need to use the CS or the CE 
statement because the Interpreter does not allow integer FOR 
variables even though in most programs the FOR variables will only 
hold integers. Therefore, if it is required to debug the program 
using the Interpreter then real variables must be used in FOR 
statements. When the program is compiled then the best performance 
will be achieved if a CS or CE statement is used to convert the FOR 
variables to integers. 3 


6. Making the most of DTL-BASIC. 

The most obvious benéfits of using DTL-BASIC are : 
~the improved performance for all compiled eben 
-~the reduced size for large compiled programs; 


-~the compatability with the Commodore Interpreter. 


There are several other benefits which are possibly not so obvious 
and this section will describe these benefits in more detail. 


1. The compiler will accept extensions to Basic implemented by 
Assembler code in ROM or RAM. 


This sounds almost too good to be true but in fact it does work. What 
happens is that when the compiler is checking the syntax of a 
statement then if it cannot recognise the first character of the 
statement (ie. if the statement does not start with either a legal 
teken or an alphabetic character) it assumes that the statement is 
valid but uses an extension to standard Commodore Basic. The compiler 
embeds the text of the statement in the program and precedes it by a 
special code. When the program is run the Run-time library detects 
this code and sets up the appropriate pointers for the Interpreter 
and calls the Interpreter (ie. the standard Commodore Interpreter in 
ROM). The Interpreter processes the statement and providing the 
program has already inserted Wedge code in page 0 (eg. by a SYS call 
or by POKES) and the Assembler routine to process the statement is in 
RAM or ROM then the statement will be obeyed. The compiler plants a 
SYS call after the special statement so that once the statement has 
been obeyed the Interpreter returns control to the Run-library. See 
Appendix D for some notes on the use of the compiler with some common 
ROM chips. 


2. Compiled programs cannot be listed or altered by the user. 


When un-compiled programs are run it iS comparatively easy for the 
user, especially one who does not know much about programming, to 
delete lines or to add new lines which will obviously have 
unpredictable effects and can appear to be errors in the original 
program. Such accidental or intended alterations to programs can 
cause many problems. With compiled programs such problems are 
avoided. In addition, as compiled programs cannot be listed other 
programmers are not able to copy individual routines or find out how 
a program works. 


3. Use of the compiler can result in Significantly reduced 
development and maintenance costs. 


Software development and maintenance costs have always been 
frighteningly high. As hardware costs come down software costs 
continue to rise. When programming in Basic on Commodore machines 
these costs can be much higher than they need to be because of the 
bad practices that have to be adopted to make Interpreted programs as 
fast and as small as possible. 


These practices (some of which are advocated by Commodore in Appendix 
E of their Basic manual) can result in programs that are 
exceptionally difficult to understand and oo modify. 


Also the program cannot be organised as a set of modules. This means 
that when new programs are developed then even if they share a 
function with an existing program it is normally -not possible to 
Simply extract useful routines from the program without the routines 
requiring modification and re-testing, If it is intended to compile a 
program once is is working then none of these bad practices need be 
used and the program can be made much easier to understand and to 
change. The program can also be made more modular. 


The bad practices referred to above include : 


~declaring the most commonly used variables at the head of the 
program; 


~placing commonly used statements at the head of the program; 
-uSing each variable for many different purposes; 

-not using many REMs; 

~putting as many statements as possible on one line; 
-~declaring all variables before any large arrays are declared; 
-not using any spaces in the program; 


-replacing parts of the program by Assembler subroutines. This 
is bad because Assembler code is far more expensive to develop 
and to maintain than Basic. 


If the program is to be compiled the sort of techniques that can be 
adopted instead of those above are : 


-organising the program as a set of independant modules with all 
related code and variables together; 


-~preceding each module with a description of it's function and a 
definition of it's variables in REM statements; 


-allocating each module a set of line numbers and variables,eg. 
Module A could use lines 5000-6000 and only use variables 
starting with the letter A; 


-defining a small set of entry points for each module; 
~having a defined interface between modules. 


If such techniques are used then each module can be considered in 
isolation from the rest of the program which makes the module much 
easier to understand and to modify. Similarly when a new program is 
to be developed then it is likely that modules can be extracted from 
existing programs and re-used without modification or re-testing. 





Basic is not a good language for serious software development but the 
use of the compiler can enable many bad practices to be avoided and 
if the above techniques are used, or others like them, then it is 
possible to produce well structured maintainable programs. 


4. Compiled programs utilise the stack more efficiently than the 
Interpreter thus enabling more complex programs to be run. 


When the Interpreter runs it uses 18 bytes of stack for each FOR 
statement (not 16 as quoted in the Commodore manual) and 5 bytes for 
each GOSUB. When a compiled program runs 10 bytes are used for each 
FOR (providing the FOR variable is an integer otherwise it also uses 
18) and 3 bytes for each GOSUB. Compiled programs can therefore have 
a greater depth of nesting than un-compiled programs. Compiled 
programs can also evaluate more complex expressions than the 
Interpreter. ’ 


7. Compatability. 


As has already been explained DTL-BASIC has been designed to achieve 
a high degree of compatability with the Commodore BASIC Interpreter, 
Obviously no two products can be totally compatible otherwise they 
would be effectively the same. For example compiled programs = run 
faster than un-compiled ones and whilst this is normally an advantage 
there can be situations where this will require the source to _ be 
altered to slow the compiled program down,eg. when a FOR loop is used 
to create a specific delay. 


This sections lists all the known incompatabilities with the 
Interpreter in the current release (some may be removed in future 
releases) ; 


-~compiled programs cannot be re-started with a CONT although the 
same effect can be achieved by typing SYS1069. 


-~calls to a user function cannot be made from the following 
statements : 


PRINT, PRINT#, INPUT, INPUT#, GET, GET#, OPEN ,CLOSE 


it is very rarely that FNs are used in such statements but if 
they occur the compiler will report an error and a minor change 
to the Source file will be required,eg.the statement : | 


PRINT "THE VALUE IS ";FNA(B) 
could be changed to 


A1=FNA(B):PRINT "THE VALUE IS ";Al 


—a compiled program can only be started at the first line by a 
Direct command,ie. by RUN and not by RUN <line number> (eg. not 
by RUN 200). Note that this does not apply to RUN. statements 
within the program. | 


-because the program is compiled the source text is not in 
memory when the program runs so that any statements that access 
the source text in any way will not work. 


~the format of the variable list is fully compatible with the 
Interpreter so that when the program is stopped variables can be 
displayed/changed via Direct commands. The only difference is 
that the order of variables in the list may be different from 
when the program runs under. the Interpreter. With the 
Interpreter the order will be the order that the variables are 
referenced at run-time; for compiled programs the order will be 
the order in which the compiler meets the variables at 
compile-time. This difference could only conceivable affect 
Assembler routines and even then it is very unlikely. 


~the format of the Array list is also the same as for the 
Interpreter although the order of the arrays in the list may 
also differ and there is one additional array in the list called 
the Array Table. The Array Table is the first array in the list 
and has a non-standard header. The Array Table is’used to hold 
pointers to the start of each normal array and is necessary 
because the addresses of arrays cannot always be calculated at 
compile time. When a program makes an array access then the 


Run-time library accesses the Array Table to -find the array - 


address. 


-when a compiled program is LOADed from another compiled program 
then the two programs cannot share variables,ie. the new program 
has its own set of variables after being LOADed. 


erm 
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8. Errors. 
The compiler performs exhaustive checks whilst compiling a program 
and reports all errors found. Errors can be found during both Pass 1 
and Pass 2. In addition, further checks are made whilst the compiled 
program is run to detect errors that cannot be found at compile time, 
There are therefore three types of errors that can occur : 

~Pass ] errors; 

~Pass 2 errors; 


-Run-time errors. 


In addition warning messages can occur during Pass l 


The following sections describe each type of error in more detail. 


8.1 Pass ] Errors. 


Pass 1 detects most errors because it checks the syntax of each 
statement. When an error is detected an error message is output 
following the line at which the error was detected. The message 
contains an error number and also indicates the position in the line 
at which the error was detected. Note that the error may be before 
the point indicated. This is because an error cannot always be 
detected immediately,eg. in an expression a missing bracket will 
normally not be apparent until the end of the expression. 


Pass 1 errors are not necessarily fatal,ie. the compiled program may 
run, provided that the statement containing the error is not 
executed. 


Appendix C contains a full list of the error numbers and their 
meanings. 


8.2 Pass 2 Errors. 


The only errors that can be found during Pass 2 are undefined -.line 
numbers;ie. a GOTO or GOSUB to a line number that does not exist. 


The error message is simply the line number containing the error 
followed by a "U" to indicate an undefined line number,eg. 


Boe J 


Programs with Pass 2 errors can also be run provided that the 
statement in error is not executed, | 


8.3 Run time errors, 


When a compiled program runs the Run-time library continually checks 
for errors and the following errors can occur ; 


~ NEXT WITHOUT FOR 
- RETURN WITHOUT GOSUB 
- OUT OF DATA 

- ILLEGAL QUANTITY 
- OVERFLOW 

- OUT OF MEMORY 

~ BAD SUBSCRIPT 

- REDIM'D ARRAY 

~ DIVISION BY ZERO 
- STRING TOO LONG 
- FILE DATA 


The above errors messages are the same as those used by the 
Interpreter. The Interpreter detects additional errors not in the 
above list (eg. syntax error) but the compiler will find these errors 
at compile time. 

The meaning of the above errors are exactly the same as for the 
Interpreter errors. Therefore, refer to the Commodore Basic manual if 
the meaning is unclear. 


The one difference between the run-time errors from compiled programs 
and from interpreted programs is that the compiled program gives the 
address of the statement containing the error rather than its line 
number. A special program called ERROR LOCATE is provided to enable 
the line number to be found. The procedure is :; 


-~make a note of the address of the error; 
-~load and run ERROR LOCATE; 
-when requested key in the program name (ie. the name of the 
Object file) and the address of the error. 
ERROR LOCATE will display the line number of the statement containing 


the error. 


Note that the above procedure will only work if the LN file for that 
program exists on drive l. 


pre. 


8.4 Warnings. 


Warning messages occur when the compiler has detected an extension to 
Basic (see section 6.1) to notify the user that an extension has been 
found. The reason for doing this is that if a syntax error occurs at 
the start of a statement the compiler will treat it as an extension 
to Basic rather than an error (there is no way that the compiler 
could separate the two cases). Therefore if warnings occur for lines 
on which the programmer did not use an extension an error must exist. 


Warning messages can be directed to either the screen or the printer 
along with any error messages and a count of the warning messages is 
output at the end of the compilation. 


If a program frequently uses extensions to Basic then many warnings 
will occur and in such a case the programmer may not require them. 
Warning messages can be turned off by the use of the No Warning 
directive( **NW) at the start of the program. In this cases. no 
warning messages will be produced but a count will still be 
generated. 


9. Use of Security Keys. 


Section 4 describes how to compile a program that will run _ on 
machines fitted with the 'Compiler' security key. 'Compiler' keys are 
only supplied together with the DTL-BASIC compiler and can therefore 
not be used by users who wish to run compiled programs on a number of 
machines. A second type of key can be supplied to fulfil this 
requirement and these keys are known as 'Run-time' keys. Any number 
of ‘Run-time’ keys: can be obtained from your supplier of DTL-BASIC. 


In order to produce a program that will run with a ‘'Run-time' key 
ensure that such a key is fitted to the machine during compilation 
(as well as the 'Compiler' key,ie. one key on each of the two 
cassette ports). When the compiler detects two keys it will produce a 
program that will run with the 'Run-time' key fitted. By making a 
number of copies of the compiled program the user can then run the 
program on any machine with a 'Run-time' key fitted. 


As compiled programs will only run on machines fitted with keys the 
user gains valuable protection for the compiled programs but if the 
standard 'Run-time' key is used this protection is not absolute as 
other users of DTL-BASIC can also obtain the standard keys. However, 
users who require complete protection can be supplied with unique 
keys which contain their own serial number. Once a serial number has 
been allocated to a particular user then only that user will be able 
to obtain keys containing that serial number. 


When the compiler detects a private 'Run-time' key during compilation 
it will first ask the user to input the serial number and will not 
compile the program unless it is input correctly. In this way only 
the registered user of a key can compile programs to use that key (as 
long as the user does not reveal the serial number to other users). 


By using DTL-BASIC together with private 'Run-time' keys a software 
supplier can obtain comprehensive protection for its products’ that 
still enables its customers to take backup copies for security and. 
can equally be be applied to cassette or Computhink disk based 
products as well as to Commodore disk based products. 


10. Future Enhancements. 


The following enhancements are being considered tor possible 
inclusion in future versions of the compiler : 3 


- the ability to specify certain sections of the program which 
are to be compiled to run as fast as possible. This feature 
would enable critical sections of the compiled program to = run 
even faster but would result in the program using more store. 


- a version of the Interpreter could be produced which would not 
perform any run-time checks (eg. such as detecting BAD SUBSCRIPT 
ERROR etc.) and which would not test the STOP key. Use of. such a 
Run-time library in fully debugged programs would result in a 
further speed improvement. A second advantage would be that the 
STOP key would be disabled but not the real-time clock. 


- a facility could be provided to enable LOADed programs to use 
the variables of the program that LOADED them,ie. to allow true 
overlays. 


- various extensions to Commodore Basic could be provided,eg. 
facilities to enable better structured programs and better 
subroutine facilities. The disadvatage of such extensions would 
be that programs that used them could not run on the 
Interpreter. 


-~ the compiler could be made to enable several source files to 
be used,ie. each subroutine or module could be in a separate 
file. As with the last feature a program that used such a 
technique would not work with the Interpreter. 


- the compiler could allow the user to specify the location for 
the compiled program so that several separately compiled 
‘programs: could reside in store at once. : 


Drive Technology Ltd welcome comments’ from users on the above 
features and on any other possible improvements to the compiler. 


Appendix A What is a compiler? 


This appendix tries to outline the main differences between a 
compiler and an interpreter. 


The first point to realise is that both a compiler and an interpreter 
are trying to achieve the same end,ie. they are both trying to 
provide a way of running a program. They both have to perform a 
Similar set of tasks it is just that these tasks are performed at 
different times. : 


Consider what has to be done to ‘run' a program. A program consists 
of a set of statements and each statement is simply a sequence of 
text characters. The program is intended by the programmer to define 
an algorithm,ie. it defines how a problem is to be solved or how a 
particular task is to be performed. The algorithm is defined in terms 
that are meaningful to the programmer but not very meaningful to the 
computer,ie. in terms of variables, operators, functions and line 
numbers etc. | 


The main tasks that have to be performed on each statement before the 
program can be run are : 


1. the type of statement must be recognised; 


2. the syntax of the statement must be checked; 

3. for each variable name detected then the list of variables 
must be searched to see if the variable has been allocated an 
address,if not an address must be allocated; 


4. for each reference to a line number {in a GOTO or a GOSUB) 
the address of that line must be determined; 


5. for each expression the operator priority rules have to be 
applied and any brackets taken in to account in order to 
determine the order of evaluating the expression; 


6. any non executable parts of the program such as spaces or 
comments (REM satements in Basic) must be skipped and ignored; 


7. finally the statement has to be obeyed. 


Both compilers and interpreters have to perform all the above tasks 
(and others); the difference is when the tasks are performed. This is 
important because most statements in a program are executed more that 
once and often many times. An interpreter performs the above tasks 
every time that a statement is executed and this means that the same 
work can be repeated many times. Such repetition is obviously 
wasteful and can be very time consuming,eg. a large program can have 
several hundred variables so that each time a variable is referenced 
a long search will be required. A compiler avoids such wasteful 
repetition by processing a program and converting it to a different 
form. In this way each of tasks 1 to 6 above are performed once only 
for each statement and only task.7 must be performed many times. 
Tasks 1 to 6 are performed when the program is compiled and only task 
7 need be performed every time the program is run. 





With an interpreter a program exists in only one form,ie. the text 
that the programmer has written. With an compiler the program has two 
forms 3; _. * 


~the text form; 
-the converted form; 


‘To distinguish between the two the text form is normally called the 
source code and the converted form the object (or binary) code. The 
object code for a statement normally contains addresses where the 
source code has variable names and/or line numbers. Similarly 
expressions are normally re-ordered to cater for operator priority 
and brackets etc. Also all redundant information such as spaces,REMS 
and line numbers etc. is omitted and complex statements are normally 
broken down to a number of simple steps. 


It should be clear from this that by pre-processing (ie. compiling) a 
program a compiler can make the program run much faster but obviously 
the compilation process takes time. The advantage of an interpreter 
is that when a program is being frequently changed (eg. when it is 
being debugged or modified) the source can simply be edited and the 
program re-run. With a compiler the program must first be re-compiled 
before a change can be tested. The two techniques are thus 
complimentary; interpreters are best during the program development 
phase but once a program is working a compiler is superior because it 
gives the best program performance. 





Appendix B Summary of Compiler Directives 


There are a number of Compiler Directives (ie. instructions to the 


compiler ) that may be incorporated within a program. The directives 
have the form of REM statements so that programs containing 
directives may still be run under the Interpreter. The standard 
format of a directive is - 7 


REM- ** <directive id> <directive text> 


This form has been chosen to minimise the chance that an existing REM 
will seen as a directive by the compiler. Also the compiler only 
looks for directives at the start of the program (ie. before any non 
REM statements have been found). 


<directive id> consists of two alphabetic characters and at present 
there are five separate directives - 


CS - Convert Specific (see section 5.6) 
CE - Convert Excluding (see section 5.6) 
SI - Special Integer (see section 5.4) 
NL ~— No Library 

NW - No Warnings (see section 8.4) 


e.g 
REM ** CS (A,B,X1,G5,GG,Z9=>ZZ$) 


means convert A,B,X1,G65,GG,2Z9 to A%,BY,X1%,G5%,GG%,2Z% 
respectively. 


REM ** CE (W4,W,FF=>F1%,MM) 


means convert all reals to integers of the same name except 
W4,W,MM which are not to be converted and FF which is to be 
converted and is to be called F1&%. 


REM ** SL 


instructs the compiler that when both operands are integer 
and the operator is either divide or exponentiation then perform 
a real operation instead of an integer operation. 


REM ** NL 


instructs the compiler to not include the Run-time library 
in the Object file. This will mean that the Object file will 
only run when it has been LOADed from within another compiled 
program but has the advantage that the Object file will need 
less disk space and will LOAD faster. Programs compiled with 
**NL should not use a simple RUN; RUN statements should be 
replaced by RUN <n> where <n> is the number of the first line of 
the program. eee | 


REM ** NW 


specifies that no warning messages are to be output during 
compilation. 
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Appendix C 


ERROR 
NUMBER 


Error Numbers 


CAUSE OF 
ERROR 


syntax error 

wrong type of operand. 

no 'TO' where one expected 

illegal array subscript 

no ‘)' where one expected 

no '(' where one expected 

no ',' where one expected 

no ';' where one expected 

no 'THEN' or 'GOTO' where one expected 

no ‘'GOTO' or 'GOSUB' where one expected 

no 'FN' where one expected 

constant too big (either > 255 or < 0) 
expression too complex 

(shouldn't occur if program is OK on Interpreter) 
syntax error in expression 

too many ')'s 

illegal operator in string ee ere 

type mismatch 

illegal statement type (either CONT or LIST) 
program too big 

(shouldn't occur if program is OK on Interpreter) 
a function name must be real 

FOR variable cannot be an array element 
wrong number of subscripts 

integer too big 

negative number illegal 

cannot set ST,TI,DS or DSS 

function variable must be real 

no function where one expected 

no operator or separator where one expected 
type mismatch in relational expression 

no line number where one expected 

no operand where one expected 

illegal CS or CE statement 

bracket missing from CS or CE statement 

too many conversion variables (> 128) 

error in CS or CE;:no'',' or ‘*=>' after name 
error in CS or CE;no '%' where one expected 
converted name clash in CS or CE 

no FNs allowed in this statement type 


(an edit 1s xYequired :—: see section 7) 


Appendix D Use of ROM chips with compiled programs 


There are an increasing number of ROM chips which can be used in CBM 
machines and many of these provide extensions to Basic. DTL-BASIC has 
special features that are designed to enable such extensions to be 
compiled, There are three main types of extensions that are used and 
these can all be handled by DTL-BASIC : 


~ wedges; ie. extensions to BaSic that are detected by a routine 
called from the CHRGET routine in page zero and to keep the ROM 
routine simple the extensions normally start with a non 
alpha-numeric character, When the compiler detects such a 
statement it embeds the whole statement in the compiled program 
and at run time passes it through to the Interpreter which picks 
up the wedge (see section 6.1). ROM routines often access Basic 
variables and arrays and as compiled programs store variables 
and arrays the same way as the Interpreter this presents no 
problems. 


Note that the only situation where wedges will not work with the 
compiler is those that start with an alphabetic character or 
which include a ":" within the statement (the compiler will 
treat the ":" as the end of the statement). 


~ extra keywords; this technique is: very. “similar <.to \a . wedge 
except that the statement starts with one of the unused token 
characters (this effectively produces extra keywords). When the 
compiler detects a statement that starts with an unused token it 
treats the statement in the same way as a wedge. The only 
complication in this case is that if a program is listed by the 
compiler the compiler does not know what keyword to associate 
with the extra tokens so that the listing will be incorrect for 


the lines containing extensions. This problem can be overcome by. 


using the direct command LIST to obtain a listing in the normal 
way instead of instructing the compiler to produce a listing. 


~ extended SYS calls; some ROM chips use SYS calls followed by 
parameters. This technique works on the Interpreter because the 
routine moves the text pointer past the parameters so that - on 
exit from the routine the Interpreter ‘sees' the end of the 
statement rather than the parameters. Such SYS calls will work 
with the compiler because on entry to the routine the text 
pointer is set to point to the first character after the routine 
address. 


Note that the parameter list should not include a ":" (other 
than at the end) as the compiler treats ":"s as the statement 
terminator. 


Ory 


The following ROM chips have been used successfully with DTL-BASIC : 


- Kram 

- Super Kram 

- Computhink disk system 

- JCL Business ROM 

~ Command-O 

~ Disk-O-Pro 

- Taylor Wilson MPS system 
(not a ROM but does use 
extensions to BaSic see 
note below) 


This is not a complete list of ROM chips that will work with the 
compiler it is simply the list of chips that have been tested so far. 
As yet no product has been found not to work so that it 1s very 
likely that other products not in the above list will work. 


The following notes are relevant to users who wish to use the above 
products with DTL-BASIC; 


1. Whilst compiled programs can include Computhink commands and can 
be run from Computhink drives the compiler itself can only be run 
from Commodore -drives. 


2. The only known problem that may occur when using the JCL Business 
ROM with compiled programs relates to the multiple statement feature 
of the PRINT AT statement. This feature allows several PRINT AT 
statements to be cascaded by the use of ":"s to separate the 
individual fields. The problem occurs because the compiler will treat 
the ":" as the end of the statement (the effect will be to cause a 
syntax error at run time); the problem can be avoided by writing the 
statements out in full, eg. 


410 PRINT@ (X,X)SS:(24-x,X)SS$ 
should be written as 
410 PRINT@ (X,X)S$:PRINT@ (24-X,X)SS 


3. All Command-O and Disk-O-Pro program statements work when compiled 
with the exception of MERGE and MERGE #¥ (which expect Basic source to 
merge and which therefore get confused by a compiled program). Also 
the DS and DSS features of Disk-O-Pro will not work. 


4. Before running the compiler then if either Command-O or Disk~O-Pro 
is enabled then perform an OUT statement from the keyboard to disable 
the enhanced screen editor. This is because the enhanced screen 
editor does not allow LOAD or DLOAD statements to be obeyed. 


5. The MPS system uses some asSsembler routines loaded to RAM to 
implement the BOPEN and BCLOSE functions. These extensions cause a 
problem because they are not implemented as true extra keywords and 
consist of the letter B followed by a keyword. As explained 
previously the compiler does not recognise extensions starting with 
an alphabetic character. This problem can be overcome by altering the 
routines in file MPS1 to look for a % instead of a B. This is 
achieved by altering location $058F from $42 to $25 and by using 
SOPEN and $CLOSE in compiled programs. 


* = 


